1. Field of the Invention
The present invention relates to a method and apparatus for Multicast Control Channel (MCCH) acquisition, and more particularly, to a method and apparatus capable of deciding whether to monitor an MCCH notification in a User Equipment (UE) of a wireless communication system according to whether the MBSFN area which broadcasts a new MBMS service is among the MBSFN areas in which the UE is receiving the MBMS services.
2. Description of the Prior Art
To enhance multimedia performance of the 3G mobile telecommunications system, the 3rd Generation Partnership Project (3GPP) introduces a Multimedia Broadcast Multicast Service (MBMS), which is a point-to-multipoint bearer service established on an existing network architecture of the Universal Mobile Telecommunications System (UMTS). MBMS allows a single source terminal to simultaneously transmit data to multiple user equipments (UEs) via Internet Protocol (IP) packets.
However, as the multimedia performance of mobile devices advances, consumers are more interested to have multimedia or mobile TV services via the mobile devices. In order to meet such requirement, the 3GPP introduces an enhanced MBMS (eMBMS) in a specification of long term evolution (LTE) Release-9, to support high quality streaming multimedia and real-time MBMS services.
The eMBMS introduces a single frequency network (SFN) operation for MBMS transmission, i.e. MBMS Single Frequency Network (MBSFN), to reduce service interruption due to frequency switching during transmissions. In MBSFN, single frequency is used by multiple cells to perform synchronized transmission at the same time, so as to save frequency resources and enhance spectrum utilization. An area covered by an MBSFN is called an MBSFN area.
In addition, only two logical channels are defined in eMBMS to support point-to-multipoint (p-t-m) downlink transmission: Multicast Control Channel (MCCH) and Multicast Traffic Channel (MTCH). MCCH is utilized for transmitting control messages of all MBMS services in an MBSFN area, and MTCH is utilized for transmitting session data of an MBMS service. The session data relates to contents of the MBMS service. Both MCCH and MTCH are mapped to a transmission channel newly defined by eMBMS, i.e. Multicast Channel (MCH).
In general, an MBSFN area has an MCCH. However, when an evolved Node B (eNB) is simultaneously covered by multiple MBSFN areas, the eNB may have multiple MCCHs. Besides, since an MBSFN area can simultaneously support multiple MBMS services, and different MBMS services may have different requirements, such as Quality of Service (QoS), Block Error Rate (BLER), according to different characteristics, an MBSFN area may have multiple MCHs. Different MCHs meet requirements of different MBMS services by applying different modulation and coding schemes. MCCH is mainly responsible for providing these MCHs with the control information. The MCCH structure is mainly governed by the following principles in LTE Release-9:
(1) The MCCH is sent on MCH.
(2) MCCH includes a Radio Resource Control (RRC) message which lists all the MBMS services with ongoing sessions.
(3) MCCH is transmitted at each repetition period.
(4) MCCH uses a modification period which is longer than a repetition period. The MCCH message of an MBSFN area remains the same during a modification period.
(5) A notification mechanism is used to announce changes of MCCH due to Session Start. An MCCH notification has the following features:                (a) An MCCH notification is transmitted with a Physical Downlink Control Channel (PDCCH) addressed to an MBMS radio network temporary identifier (M-RNTI).        (b) Timing for transmission of an MCCH notification is for further study (FFS), and can be based on paging occasion or special M-RNTI occasion.        (c) After receiving an MCCH notification, the UE acquires MCCH during the next modification period. In other words, since the MCCH message remains the same during a modification period, the UE should acquire MCCH changed due to Session Start during the next modification period after receiving an MCCH notification.        
(6) The UE is informed of changes other than Session Start, such as Session Stop, PMCH reconfiguration, etc., by monitoring MCCH message at each modification period.
The principle (5) states that the MCCH notification mechanism is used to announce changes of MCCH due to Session Start, and (6) states that the UE needs to monitor MCCH message at each modification period, to acquire changes other than Session Start. (5) and (6) seem to imply that if a UE expresses interest in reception of a new MBMS service, the UE must monitor an MCCH notification to acquire an MCCH message about Session Start of the new MBMS service. For a UE which does not start receiving any MBMS service, the UE only needs to acquire MCCH at the next modification period after receiving the MCCH notification instead of frequently monitoring MCCH at each modification period, and thus can save power.
However, for a UE which is receiving MBMS services and expresses interest in reception of another new MBMS service, it is not absolutely necessary for the UE to receive an MCCH notification. Whether the UE needs to receive an MCCH notification mainly depends on whether the MBSFN area which broadcasts the new MBMS service is among the MBSFN areas in which the UE is receiving the MBMS services. If the MBSFN area which broadcasts the new MBMS service is among the MBSFN areas in which the UE is receiving the MBMS services, since the UE acquires the same MCCH message no matter whether via the MCCH notification mechanism or by periodically monitoring MCCH, the UE can be aware of Session Start of the new MBMS service by acquiring the MCCH message of the concerned MBSFN area at each modification period. Therefore, requesting a UE interested in reception of a new MBMS service to always monitor an MCCH notification is not appropriate. In other words, if the MBSFN area which broadcasts the new MBMS service is among the MBSFN areas in which the UE is receiving the MBMS services, it is unnecessary for the UE to monitor the MCCH notification, and it is only a waste of UE power. Thus, there is a need for improvement.